Simulations of software applications are typically created by running special programs referred to as simulation generation software. The simulation generation software is designed to monitor a simulation developer's interaction with another application, e.g., target software, and the changes that result from those interactions. For example, the simulation generation software records a stream of images and events, similar to a movie, of the interactions between the target software and the developer. These interactions can then be replayed to simulate the target software in order to teach a user specific features of the target software. The simulation generation software also allows the simulation developer to modify and enhance the simulation.
Like a movie, the initial simulation is a single path of execution, in which the flow of events follows one possible path through the target software. By way of illustration, a developer may wish to simulate a copy and paste operation for a word processing application. In this example, the developer may perform the following operation, in a single path flow:
(i) Highlight a specific word or words;
(ii) Click on “Edit” and scroll to and highlight “Copy”;
(iii) Move the cursor to a desired location; and
(iv) Click on “Edit” and scroll to and highlight “Paste”.
During these operations, the simulation generation software will record these actions in a single path, for future playback. Once recorded, the information will be presented to a student, as a simulation, in a single simulation path. In this manner, the student can perform the simulated operations, along with the simulation generation software.
A more sophisticated type of simulation is one with multi-path execution. In this more sophisticated simulation the users of the simulation are allowed to take more than one path of execution through the simulation. Typically, this is referred to as multi-path simulations, which contain options at specific junctions in the simulation that permit branching to a different section of the simulation thereby mimicking a different path in the target software.
By way of example, using the same copy and paste illustration, it is known that there are several different ways in which to accomplish this operation. For example, in addition to the above, the developer may wish to teach the following operation:
(i) Highlight a specific word or words;
(ii) Depress the “Ctrl” and “C” buttons on the keyboard;
(iii) Move the cursor to a desired location; and
(iv) Depress the “Ctrl” and “P” buttons on the keyboard.
However, to generate the multi-path simulation, two or more single path simulations must be manually combined. That is, in the illustrated example, the two simulations must be combined with a branching occurring between the (i) and (ii) operations. Branching to the different sections of the simulation must be manually added to the simulation stream, which is time consuming and tedious. This includes, for example, editing and/or erasing operations, which were recorded when returning back to a beginning point of the two simulations.
In either scenario, often, during the process of creating application simulations, it is necessary that the target software be a “live” system; that is, the target software has real world information such as user information (e.g., user id, password, address, Social Security number, etc.), billing codes, and access information. This is information that is considered confidential; that is, information that the simulation developer does not want the user of the simulation to be exposed to or have knowledge of during the training session. Accordingly, this data must be substituted in the simulation with similar, but fictitious, information.
The problem lies in the fact that the “live” information within the simulation exists not only as expected textual answers to be inputted by the simulation user but also as the graphical representation of that text on the simulations' background. Thus, if a simulation developer is to replace the graphical representation of the text, then the developer must manually create a new graphic matching the characteristics for the graphical representation of the new text (e.g., the text itself with the correct font, font color, background color, etc.) which is very time consuming and tedious. In fact, if during the course of the simulation, a section of the graphical representation of the text is partially obscured, the simulation developer must create another, partial, graphic of the new text and place that new graphic on the required screens.
Accordingly, there exists a need in the art to overcome the deficiencies and limitations described hereinabove.